SYSTEMD.RESOURCE-CONTROL(5) | systemd.resource-control | SYSTEMD.RESOURCE-CONTROL(5) |
NAME¶
systemd.resource-control - Resource control unit settings
SYNOPSIS¶
slice.slice, scope.scope, service.service, socket.socket, mount.mount, swap.swap
DESCRIPTION¶
Unit configuration files for services, slices, scopes, sockets, mount points, and swap devices share a subset of configuration options for resource control of spawned processes. Internally, this relies on the Linux Control Groups (cgroups) kernel concept for organizing processes in a hierarchical tree of named groups for the purpose of resource management.
This man page lists the configuration options shared by those six unit types. See systemd.unit(5) for the common options of all unit configuration files, and systemd.slice(5), systemd.scope(5), systemd.service(5), systemd.socket(5), systemd.mount(5), and systemd.swap(5) for more information on the specific unit configuration files. The resource control configuration options are configured in the [Slice], [Scope], [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type.
In addition, options which control resources available to programs executed by systemd are listed in systemd.exec(5). Those options complement options listed here.
See the New Control Group Interfaces[1] for an introduction on how to make use of resource control APIs from programs.
IMPLICIT DEPENDENCIES¶
The following dependencies are implicitly added:
UNIFIED AND LEGACY CONTROL GROUP HIERARCHIES¶
The unified control group hierarchy is the new version of kernel control group interface, see cgroup-v2.txt[2]. Depending on the resource type, there are differences in resource control capabilities. Also, because of interface changes, some resource types have separate set of options on the unified hierarchy.
CPU
The "cpuacct" controller does not exist separately on the unified hierarchy.
Memory
IO
To ease the transition, there is best-effort translation between the two versions of settings. For each controller, if any of the settings for the unified hierarchy are present, all settings for the legacy hierarchy are ignored. If the resulting settings are for the other type of hierarchy, the configurations are translated before application.
Legacy control group hierarchy (see cgroups.txt[3]), also called cgroup-v1, doesn't allow safe delegation of controllers to unprivileged processes. If the system uses the legacy control group hierarchy, resource control is disabled for systemd user instance, see systemd(1).
OPTIONS¶
Units of the types listed above can have settings for resource control configuration:
CPUAccounting=
CPUWeight=weight, StartupCPUWeight=weight
While StartupCPUWeight= only applies to the startup phase of the system, CPUWeight= applies to normal runtime of the system, and if the former is not set also to the startup phase. Using StartupCPUWeight= allows prioritizing specific services at boot-up differently than during normal runtime.
Implies "CPUAccounting=true".
These settings replace CPUShares= and StartupCPUShares=.
CPUQuota=
Example: CPUQuota=20% ensures that the executed processes will never get more than 20% CPU time on one CPU.
Implies "CPUAccounting=true".
AllowedCPUs=
Setting AllowedCPUs= doesn't guarantee that all of the CPUs will be used by the processes as it may be limited by parent units. The effective configuration is reported as EffectiveCPUs=.
This setting is supported only with the unified control group hierarchy.
AllowedMemoryNodes=
Setting AllowedMemoryNodes= doesn't guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units. The effective configuration is reported as EffectiveMemoryNodes=.
This setting is supported only with the unified control group hierarchy.
CPUQuotaPeriodSec=
This controls the second field of "cpu.max" attribute on the unified control group hierarchy and "cpu.cfs_period_us" on legacy. For details about these control group attributes, see cgroup-v2.txt[2] and sched-design-CFS.txt[4].
Example: CPUQuotaPeriodSec=10ms to request that the CPU quota is measured in periods of 10ms.
MemoryAccounting=
MemoryMin=bytes
Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which is taken relative to the installed physical memory on the system. This controls the "memory.min" control group attribute. For details about this control group attribute, see cgroup-v2.txt[2].
Implies "MemoryAccounting=true".
This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
Units may have their children use a default "memory.min" value by specifying DefaultMemoryMin=, which has the same semantics as MemoryMin=. This setting does not affect "memory.min" in the unit itself.
MemoryLow=bytes
Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which is taken relative to the installed physical memory on the system. This controls the "memory.low" control group attribute. For details about this control group attribute, see cgroup-v2.txt[2].
Implies "MemoryAccounting=true".
This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
Units may have their children use a default "memory.low" value by specifying DefaultMemoryLow=, which has the same semantics as MemoryLow=. This setting does not affect "memory.low" in the unit itself.
MemoryHigh=bytes
Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which is taken relative to the installed physical memory on the system. If assigned the special value "infinity", no memory limit is applied. This controls the "memory.high" control group attribute. For details about this control group attribute, see cgroup-v2.txt[2].
Implies "MemoryAccounting=true".
This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
MemoryMax=bytes
Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a percentage value may be specified, which is taken relative to the installed physical memory on the system. If assigned the special value "infinity", no memory limit is applied. This controls the "memory.max" control group attribute. For details about this control group attribute, see cgroup-v2.txt[2].
Implies "MemoryAccounting=true".
This setting replaces MemoryLimit=.
MemorySwapMax=bytes
Takes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified swap size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the special value "infinity", no swap limit is applied. This controls the "memory.swap.max" control group attribute. For details about this control group attribute, see cgroup-v2.txt[2].
Implies "MemoryAccounting=true".
This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.
TasksAccounting=
TasksMax=N
Implies "TasksAccounting=true". The system default for this setting may be controlled with DefaultTasksMax= in systemd-system.conf(5).
IOAccounting=
This setting replaces BlockIOAccounting= and disables settings prefixed with BlockIO or StartupBlockIO.
IOWeight=weight, StartupIOWeight=weight
While StartupIOWeight= only applies to the startup phase of the system, IOWeight= applies to the later runtime of the system, and if the former is not set also to the startup phase. This allows prioritizing specific services at boot-up differently than during runtime.
Implies "IOAccounting=true".
These settings replace BlockIOWeight= and StartupBlockIOWeight= and disable settings prefixed with BlockIO or StartupBlockIO.
IODeviceWeight=device weight
Implies "IOAccounting=true".
This setting replaces BlockIODeviceWeight= and disables settings prefixed with BlockIO or StartupBlockIO.
IOReadBandwidthMax=device bytes, IOWriteBandwidthMax=device bytes
Implies "IOAccounting=true".
These settings replace BlockIOReadBandwidth= and BlockIOWriteBandwidth= and disable settings prefixed with BlockIO or StartupBlockIO.
IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS
Implies "IOAccounting=true".
These settings are supported only if the unified control group hierarchy is used and disable settings prefixed with BlockIO or StartupBlockIO.
IODeviceLatencyTargetSec=device target
Implies "IOAccounting=true".
These settings are supported only if the unified control group hierarchy is used.
IPAccounting=
When this option is used in socket units, it applies to all IPv4 and IPv6 sockets associated with it (including both listening and connection sockets where this applies). Note that for socket-activated services, this configuration setting and the accounting data of the service unit and the socket unit are kept separate, and displayed separately. No propagation of the setting and the collected statistics is done, in either direction. Moreover, any traffic sent or received on any of the socket unit's sockets is accounted to the socket unit — and never to the service unit it might have activated, even if the socket is used by it.
The system default for this setting may be controlled with DefaultIPAccounting= in systemd-system.conf(5).
IPAddressAllow=ADDRESS[/PREFIXLENGTH]..., IPAddressDeny=ADDRESS[/PREFIXLENGTH]...
The access lists configured with this option are applied to all sockets created by processes of this unit (or in the case of socket units, associated with it). The lists are implicitly combined with any lists configured for any of the parent slice units this unit might be a member of. By default all access lists are empty. When configured the lists are enforced as follows:
In order to implement a whitelisting IP firewall, it is recommended to use a IPAddressDeny=any setting on an upper-level slice unit (such as the root slice -.slice or the slice containing all system services system.slice – see systemd.special(7) for details on these slice units), plus individual per-service IPAddressAllow= lines permitting network access to relevant services, and only them.
Note that for socket-activated services, the IP access list configured on the socket unit applies to all sockets associated with it directly, but not to any sockets created by the ultimately activated services for it. Conversely, the IP access list configured for the service is not applied to any sockets passed into the service via socket activation. Thus, it is usually a good idea, to replicate the IP access lists on both the socket and the service unit, however it often makes sense to maintain one list more open and the other one more restricted, depending on the usecase.
If these settings are used multiple times in the same unit the specified lists are combined. If an empty string is assigned to these settings the specific access list is reset and all previous settings undone.
In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic names may be used. The following names are defined:
Table 1. Special address/network names
Symbolic Name | Definition | Meaning |
any | 0.0.0.0/0 ::/0 | Any host |
localhost | 127.0.0.0/8 ::1/128 | All addresses on the local loopback |
link-local | 169.254.0.0/16 fe80::/64 | All link-local IP addresses |
multicast | 224.0.0.0/4 ff00::/8 | All IP multicasting addresses |
Note that these settings might not be supported on some systems
(for example if eBPF control group support is not enabled in the underlying
kernel or container manager). These settings will have no effect in that
case. If compatibility with such systems is desired it is hence recommended
to not exclusively rely on them for IP security.
DeviceAllow=
The device node specifier is either a path to a device node in the file system, starting with /dev/, or a string starting with either "char-" or "block-" followed by a device group name, as listed in /proc/devices. The latter is useful to whitelist all current and future devices belonging to a specific device group at once. The device group is matched according to filename globbing rules, you may hence use the "*" and "?" wildcards. Examples: /dev/sda5 is a path to a device node, referring to an ATA or SCSI block device. "char-pts" and "char-alsa" are specifiers for all pseudo TTYs and all ALSA sound devices, respectively. "char-cpu/*" is a specifier matching all CPU related device groups.
DevicePolicy=auto|closed|strict
strict
closed
auto
Slice=
This option may be used to arrange systemd units in a hierarchy of slices each of which might have resource settings applied.
For units of type slice, the only accepted value for this setting is the parent slice. Since the name of a slice unit implies the parent slice, it is hence redundant to ever set this parameter directly for slice units.
Special care should be taken when relying on the default slice assignment in templated service units that have DefaultDependencies=no set, see systemd.service(5), section "Default Dependencies" for details.
Delegate=
Note that controller delegation to less privileged code is only safe on the unified control group hierarchy. Accordingly, access to the specified controllers will not be granted to unprivileged services on the legacy hierarchy, even when requested.
The following controller names may be specified: cpu, cpuacct, io, blkio, memory, devices, pids. Not all of these controllers are available on all kernels however, and some are specific to the unified hierarchy while others are specific to the legacy hierarchy. Also note that the kernel might support further controllers, which aren't covered here yet as delegation is either not supported at all for them or not defined cleanly.
For further details on the delegation model consult Control Group APIs and Delegation[7].
DEPRECATED OPTIONS¶
The following options are deprecated. Use the indicated superseding options instead:
CPUShares=weight, StartupCPUShares=weight
While StartupCPUShares= only applies to the startup phase of the system, CPUShares= applies to normal runtime of the system, and if the former is not set also to the startup phase. Using StartupCPUShares= allows prioritizing specific services at boot-up differently than during normal runtime.
Implies "CPUAccounting=true".
These settings are deprecated. Use CPUWeight= and StartupCPUWeight= instead.
MemoryLimit=bytes
Implies "MemoryAccounting=true".
This setting is deprecated. Use MemoryMax= instead.
BlockIOAccounting=
This setting is deprecated. Use IOAccounting= instead.
BlockIOWeight=weight, StartupBlockIOWeight=weight
While StartupBlockIOWeight= only applies to the startup phase of the system, BlockIOWeight= applies to the later runtime of the system, and if the former is not set also to the startup phase. This allows prioritizing specific services at boot-up differently than during runtime.
Implies "BlockIOAccounting=true".
These settings are deprecated. Use IOWeight= and StartupIOWeight= instead.
BlockIODeviceWeight=device weight
Implies "BlockIOAccounting=true".
This setting is deprecated. Use IODeviceWeight= instead.
BlockIOReadBandwidth=device bytes, BlockIOWriteBandwidth=device bytes
Implies "BlockIOAccounting=true".
These settings are deprecated. Use IOReadBandwidthMax= and IOWriteBandwidthMax= instead.
SEE ALSO¶
systemd(1), systemd.unit(5), systemd.service(5), systemd.slice(5), systemd.scope(5), systemd.socket(5), systemd.mount(5), systemd.swap(5), systemd.exec(5), systemd.directives(7), systemd.special(7), The documentation for control groups and specific controllers in the Linux kernel: cgroups.txt[3], cpuacct.txt[10], memory.txt[8], blkio-controller.txt[9].
NOTES¶
- 1.
- New Control Group Interfaces
- 2.
- cgroup-v2.txt
- 3.
- cgroups.txt
- 4.
- sched-design-CFS.txt
- 5.
- pids.txt
- 6.
- devices.txt
- 7.
- Control Group APIs and Delegation
- 8.
- memory.txt
- 9.
- blkio-controller.txt
- 10.
- cpuacct.txt
systemd 239 |